接觸到 Scrum 是大約在 2008 年的時候, 那時候我的團隊成員跟我說想要跑 Scrum, 那時候為了表示我是位開明的主管, 於是我就說好, 可是那時候我並不懂什麼是 Scrum. 但是我們就這樣開始了.

那時候執行的還蠻成功的, 事後想想有幾個關鍵的因素：

(1) 由下發起：在好的東西, 下面沒有覺得好, 你想強加只會事倍功半.
(2) 上面支持：因為我是老大, 我願意支持, 自然事情就簡單多了
(3) 沒有歷史包袱：因為是 1.0 的產品, 沒有舊東西要改, 跟其他團隊元件關聯性低

之後在不同團隊或不同專案上實踐 Scrum, 就再也沒有這麼幸運過, 挑戰一大堆, 團隊成員大多是自己養的, 是有機會可以談談. 但是最難的部分是跨團隊的合作, 因為在大公司中, 通常產品不會很單純, 需要多個團隊一起來配合. 這時候別的團隊就不會受你控制, 或者雖然他們願意配合, 你也需要有套有效的方式來協作. 可是 Scrum 或是其他敏捷開發方法, 都是專注在單一團隊, 或者是開發實務上面, 對於多團隊的合作要怎麼跑敏捷, 並沒有標準的作法或是框架可以遵循. 因此, 都只能在單一團隊上玩玩 Scrum.

最先提到多團隊合作的作法就是 Scrum of Scrums. 這是最初大型專案用來進行大規模 Scrum 的技巧. 這個會議會週期性進行, 讓多個團隊來討論他們之間要協作的工作, 著重於整合和互相影響的問題.

想像一下, 如果有一個大型的專案, 裡面有 7 個 Scrum 團隊, 每個團隊有 7 個人, 每個團隊會進行他們自己的Daily Scrum. 然後它們會指派一個人去參加 Scrum of Scrums 會議. 這個指派的是由每個團隊自行決定. 通常來說, 這個人是技術導向的角色, 像是開發人員, 測試人員, DBA 或用戶體驗設計師, 通常不會是 Product Owner或是 Scrum Master.

被指定參加的人不需要永遠固定不變的, 需要根據會議的目的或是專案的階段, 找出最佳最適合的代表. 像是在早期, 可能主要是要討論用戶體驗設計或是架構設計. 而在後期, 可能著重於如何整合或測試. 如果團隊數目不多, 像是只有4 個 Scrum 團隊, 這時候 Scrum of Scrums 會議, 每個團隊就可以派兩個人來參加.

Scrum of Scrums 會議可以以遞迴的方式不斷地擴大. 讓我們看一下下面這張圖

圖片來源: https://www.microtool.de/en/knowledge-base/what-is-the-scrum-of-scrums/

這裡有 7 個 Scrum 團隊, 每個團隊會有一個代表(就像前面所提到的). 這些代表可以進行 Scrum of Scrums 的會議, 也就是 high level 的 Daily Scrum 會議(像圖中的第二層所示). 而這些 Scrum of Scrums 團隊, 還可以找出代表, 再進行更高層的 Scrum of Scrums of Scrums 會議 (就像圖中最上面一層所示)

但是這樣的作法有很大的問題：

(1) 開會無法解決知識不會就是不會的問題

很多時候領域知識或者對某段程式碼/元件的了解, 不是開會就可以了解或者是學會, 需要有更進一步的方法.

(2) Scrum of Scrums 不即時

通常是每天一次, 或者是一週 2-3 次. 但是有時候問題發生時就要立即處理, 無法等到每天一次或是每週 2-3 次那時候.

(3) 不是所有的事情與會代表都懂

人不是神, 不是你代表來開會就會懂全部. 有些人只是懂需求, 有些人懂技術. 所以可能還需要帶回去討論後, 再來這個會議討論, 一來一往就耗掉很多時間.

(4) 不是每件事情都跟大家有關

有些事情只跟某幾個團隊有關, 但是當下是所有團隊的代表都在那邊, 雖然說可以學習新的東西, 但是久了也是會讓人覺得心煩.

後來在 2015 年時聽到 Bas Vodde 他們要推出大規模敏捷的框架時(他們稱為 LeSS, Large Scale Scrum), 內心是感到非常期待, 想知道是不是能夠解決之前遇到的問題. 不過當下動機不是很大, 因為在那個時間點, 台灣敏捷落實狀況不是很好, 很多公司沒有聽過, 覺得沒有這個需要. 就算有公司開始使用, 也是屬於剛開始的階段, 連 Scrum 都搞不太定, 因此, 就只是買了書, 隨意翻了一下, 沒有太用力去了解.

後來到了 2018, 2019 年後, 台灣的大環境越來越多公司開始提到敏捷, 也開始執行 Scrum. 在經過幾年大家在 Scrum 實施的技能也逐漸成熟, 也應用到更多團隊更多場景中. 再加上國外也越來越多大規模敏捷的框架提出, 像是Scaled Agile Framework (SAFe), Nexus, Scrum@Scale, 和 Disciplined Agile (DA) 等等. 因此, 確實是一個好的時機點再來看看這些框架.

後來出來當敏捷教練後, 接觸很多客戶, 他們在開發過程中實施 LeSS, 或者是正要開始實施 LeSS, 並且很幸運地當時有機會跟 LeSS華人第一高手呂毅合作, 也就是 Odd-e 的大師兄, 他對 LeSS的了解十分深入, 能夠在他身邊打下手, 過程學習到很多, 讓我對 LeSS 有了不同層次的認識. 因此, 想要趁這次鐵人賽的機會, 好好整理這段時間內所學習到的東西. 希望能夠對 LeSS 的推廣有幫助, 能夠讓更多人對 LeSS 有更深入的了解.